home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1599 / 1334 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  4.4 KB
  1. From: Stephen Usher <Stephen.Usher@earth.ox.ac.uk>
  2. Subject: Re: Just a couple of things.
  3. Date: Wed, 27 Apr 1994 10:01:46 +0100 (BST)
  4. In-Reply-To: <9404270825.AA19506@hpbeo79.bbn.hp.com> from "Claus Brod" at Apr 27, 94 10:25:48 am
  5. Mime-Version: 1.0
  6.  
  7. >> Filesystems would layer above this model. As the Falcon SCSI and TT SCSI are
  8. >> mutually exclusive they could use the same virtual device numbers. Devices
  9. >> would be numbered in the same way as Atari does, ie. ACSI are 0-7 and SCSI
  10. >> are 8-15.
  11. >> 
  12. >> To do this I'll need to get information on the following:-
  13. >> 
  14. >> (a) SCSI commands
  15. >> (b) TT SCSI chip programming
  16. >> (c) Falcon SCSI hardware addresses and programming
  17. >
  18. >You're reinventing the wheel here. It would be much more efficient
  19. >in terms of developping time if we could agree on an XHDI extension
  20. >which allows to send ACSI/SCSI commands to the hard disk driver.
  21. >This way, you would only have to write the device driver interface
  22. >code and wouldn't have to care about low-level stuff. 
  23.  
  24. I think the important thing, however, is to integrate SCSI/ACSI into a
  25. MiNT-level driver rather than one below it so that it can fully integrate
  26. with MiNT so that the whole machine doesn't just hang every time you do a
  27. disk access, as the current ACSI/SCSI drivers tend to do.
  28.  
  29. The senario I'd like to see is something like this:-
  30.  
  31. A process wants to send a command to a SCSI device which may take a while to
  32. respond. It uses the SCSI API layer to send the command. The SCSI device
  33. driver sends the command, disconnects from the device, puts the process
  34. on an I/O wait queue and returns control to MiNT. Sometime later the device
  35. responds to the command, the SCSI driver notices, passes the reply into the
  36. address space of the process and puts the process on the run queue.
  37.  
  38. A device driver below MiNT cannot do this.
  39.  
  40. >The only problem here is that you need a hard disk driver that offers
  41. >such a service. Atari will certainly not update their hard disk driver
  42. >in that direction, and I don't think that ICD offers a full XHDI
  43. >interface. Therefore I have the following suggestion:
  44. >
  45. >A few years ago, I wrote a hard disk driver of my own, called CBHD.
  46. >It has been published as part of a book that I wrote ("Scheibenkleister"),
  47. >together with other hard disk maintenance software. At the time,
  48. >the book and the driver were very successful in Germany.
  49.  
  50. It would be a good starting place for the driver code. It's important that
  51. the code is also forward looking, able to handle devices with sizes greater
  52. than 4GB etc. This would mean being able to support at least 64bit block
  53. numbers.
  54.  
  55. >In the meantime, the book is out of print, and I don't have the
  56. >time to offer a full-blown support for the hard disk driver.
  57. >I know, however, that it is quite good; it's fast (I believe
  58. >it is the fastest of them all 8-), reliable (thousands of users
  59. >have tested it with quite a lot of configurations), and in the
  60. >meantime it has also become a little more modular so that it can 
  61. >be extended more easily. I don't want this piece of software just 
  62. >lie around on my hard disk. If there's enough interest, I would be willing
  63. >to give this hard disk driver into the public domain, under similar
  64. >terms as other MiNT-related software and MiNT itself so that other
  65. >people could hack it up and extend it. I have prepared the driver
  66. >for XHDI support, but only two or three XHDI functions are implemented
  67. >right now. It's not that tricky to add the other ones, though.
  68. >I just don't have the time for it. I would be willing, though,
  69. >to coordinate releases, i.e. collect, check and send out patches,
  70. >at least in the beginning until I have found out whether this
  71. >is manageable or not.
  72. >
  73. >So if you think a PD hard disk driver would be a good idea, please
  74. >say so. I need some support for it, and I won't release CBHD into
  75. >the public domain if I don't know that there will be some people
  76. >who will actually add value to it and use it. 
  77.  
  78. Anything would be better than AHDI, ICD and their kin! :-)
  79.  
  80. >Let me know what you think!
  81. >
  82. >--clausb@hpbeo79.bbn.hp.com-----------------------------------------------
  83. >Claus Brod, MDD, HP Boeblingen         Have you hugged your manager today?
  84. >--#include <std_disclaimer>-----------------------------------------------
  85.  
  86. Steve
  87.  
  88. -- 
  89. ---------------------------------------------------------------------------
  90. Computer Systems Administrator, Dept. of Earth Sciences, Oxford University.
  91. E-Mail: steve@uk.ac.ox.earth (JANET) steve@earth.ox.ac.uk (Internet).
  92. Tel:- Oxford (0865) 282110 (UK) or +44 865 282110 (International).
  93.